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Abstract 

Requirements-to-Design-to-Code (R2D2C) is an ap- 
proach to the engineering of computer-based systems 
that embodies the idea of requirements-based program- 
ming in system development. It goes further, however, in 
that the approach offers not only an underlying formal- 
ism, but full formal development from requirements capture 
through to the automatic generation of provably-correct 
code. As such, the approach has direct application to the de- 
velopment of systems requiring autonomic properties. We 
describe a prototype tool to support the method, and il- 
lustrate its applicability to the development of LOGOS, 
a NASA autonomous ground control system, which ex- 
hibits autonomic behavior. Finally, we briefly discuss other 
areas where the approach and prototype tool are being con- 
side red for application. 


1. Introduction 

We have advocated that computer-based systems should 
be autonomic [20], and, more specifically, that autonomous 
systems are necessarily autonomic [21]. Clearly, too, auto- 
nomic systems are inherently autonomous, as they are re- 
quired to necessarily adapt and evolve to meet their goals 
of being self healing, self configuring, self optimizing, and 
self protecting. 

Such systems can prove to be exceedingly complex, and 
consequently their development extremely difficult. Often, 
the complete behavior of the system cannot be foreseen at 
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the outset, partly because of the evolving nature of the sys- 
tem, and partly because it is difficult to capture all of the 
necessary domain knowledge before development begins. 
Because of this and the system’s emergent behavior (that 
is, behavior that is exhibited by a system as it evolves, but 
which was not anticipated) the system cannot be fully tested 
using traditional methods [18]. 

Clearly formal methods can go a long way towards solv- 
ing these problems, and can reduce reliance on testing. 
However, they are still perceived to be difficult to use [4], 
and their uptake in industry has not been as commonplace 
as one would have expected. 

2. Requirements-Based Programming 
2.1. Background 

Requirements-Based Programming (RBP) has been ad- 
vocated [7, 8] as a viable means of developing complex, 
evolving systems. It embodies the idea that requirements 
can be systematically and mechanically transformed into 
executable code. 

This may seem to be an obvious goal in the engineer- 
ing of computer-based systems, but RBP does in fact go a 
step further than current development methods. System de- 
velopment, typically, assumes the existence of a model of 
reality, called a design (or, more correctly, a design specifi- 
cation), from which an implementation will be derived. This 
model must itself be derived from the system requirements, 
but there is a large “gap” in going from requirements to de- 
sign [11]. RBP seeks to eliminate this “gap” by ensuring 
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Figure 1. The R2D2C approach and current status of the prototype. 


that the ultimate implementation can be fully traced back to 
the actual requirements (although, as proposed by its advo- 
cates, it does not necessarily entail full mathematical prov- 
ability of the equivalence of a set of requirements and its 
implementation). 


2.2. R2D2C 


R2D2C (Requirements-to-Design-to-Code) is a NASA 
patent-pending approach to the engineering of complex 
computer systems, where the need for correctness of the 
system, with respect to its requirements, is particularly high. 
This category includes NASA mission software, most of 
which exhibits both autonomous and autonomic properties. 

The approach, described in greater detail in [11], em- 
bodies the main idea of requirements-based programming. 
It goes further, however, in that the approach offers not only 
an underlying formalism, but also full formal development 
from requirements capture through to automatic generation 
of provably correct code. Moreover, the approach can be 
adapted to generate instructions in formats other than con- 
ventional programming languages; these include, for exam- 
ple, instructions for controlling physical devices, and rules 
embodying the knowledge contained in expert systems. In 
these contexts, NASA is currently applying the approach 
to the verification of the instructions and procedures to be 
generated by the Hubble Space Telescope Robotic Servic- 
ing Missions (HRSM) and in the validation of the rule base 
used in the ground control of the ACE spacecraft. 

In the remainder of this paper we describe a prototype 
tool to support the R2D2C method and report on our expe- 
riences in applying it to validate the prototype Lights-Out 
Ground Operations System (LOGOS), an autonomous sys- 
tem exhibiting autonomic properties [21, 22]. 


3. Requirements to Design to Code 

R2D2C takes, as input, system requirements written by 
engineers (and others) as scenarios in natural language, or 
UML use cases, or some other appropriate graphical or tex- 
tual representation. From the scenarios, an automated theo- 
rem prover in which the laws of concurrency [9] have been 
embedded infers a corresponding process-based specifica- 
tion expressed in an appropriate formal language (currently 
we are using CSP, Hoare’s language of Communicating Se- 
quential Processes [13, 14]). 

A process-based specification is far more amenable to 
analysis, and also forms a more appropriate basis for code 
generation. As much as possible, R2D2C makes use of 
widely-available tools and notations that are well-trusted 
and that have been demonstrated to be useful in the devel- 
opment of high-quality systems. 

A “short-cut” approach to R2D2C [10, 1 1] avoids the use 
of an automated theorem prover, which is computationally 
expensive. This alternative approach involves the inference 
of a corresponding process-based specification (in a lan- 
guage we have named EzyCSP) without a theorem prover, 
but requires a (one time) proof of the translation in order 
to preserve the mathematical underpinnings of the R2D2C 
approach. Figure 1 illustrates those parts of the approach 
for which we have built a prototype tool (described in the 
remainder of this paper), and shows where commercially- 
available and public domain tools may be used to support 
the approach. 

3.1. Prototype Tool 

The CSP formal model is the central part of the proposed 
approach, which conforms to a Model Driven Architecture 
(MDA) [15]. The prototype tool automatically generates the 
code from the CSP model (or design) (Figure 2) into which 
the tool has already transformed the requirements. 

In order to develop a tool based on CSP, two major is- 
sues must be addressed — how to translate the CSP model 
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Figure 2. MDA approach 


into code and how to translate the requirements into the CSP 
model. The tool transforms the derived design (CSP model) 
into an equivalent software representation (code) using Java 
as the target programming language. There were several 
reasons for selecting the Java programming language [6] 
both for tool implementation and for the target platform: 

• Java is a general-purpose, concurrent, class-based, 
object-oriented programming language, with very few 
implementation and hardware dependencies. 

• An off-the-shelf implementation (library) of CSP 
for Java [2] is available. While JCSP does not pro- 
vide direct CSP-to-Java mapping, it conforms to 
the CSP model of communicating systems for Java 
multi- threaded applications [16]. There is also support 
for distributed JCSP components using JCSP.net [24]. 

• Java Swing [23], in combination with some available 
Java IDEs, greatly simplifies user interface develop- 
ment. 

• Many Java-based translator development tools are 
available. 

The prototype tool implementation in Java uses off-the- 
shelf components. A Swing-based user interface provides a 
transparent layer for entering the requirements and viewing 
the resulting model. Figure 3 shows the high-level program 
flow. 

The translators are implemented using the ANTLR [1] 
tool, which provides a framework for constructing recogniz- 
ers, compilers, and translators from grammatical descrip- 
tions. A discussion of ANTLR and some related tools can 
be found in [19]. An English-like input language, specified 
as an ANTLR grammar, is used to specify user requirements 
(Figure 4). ANTLR uses the grammar to automatically gen- 
erate the translator. The translator is then used to generate 
the CSP model that corresponds to the user requirements 
(Figure 5). Figure 6 shows the graph-based representation 
of the system (under development). 


4. Experiences in Applying the Prototype Tool 

4.1. LOGOS 

The Lights-Out Ground Operations System (LOGOS) 
is a proof-of-concept NASA system for automatic control 
of ground stations when satellites pass overhead and under 
their control. LOGOS is a community of autonomous soft- 
ware agents, exhibiting autonomic behavior and cooperat- 
ing to perform the functions that in the past have been per- 
formed by human operators using traditional software tools 
such as orbit generators and command sequence planners. It 
is designed to operate in “lights out” mode (i.e., without hu- 
man intervention except in situations where problems and 
anomalies can no longer be dealt with by the system itself)* 
See [18] and [21] for more detailed discussion of LOGOS 
and its autonomic properties. 

4.2. LOGOS in R2D2C 

We will not consider the entire LOGOS system here. Al- 
though a relatively small system, it is too extensive to illus- 
trate in its entirety in this paper. Instead, we will take a cou- 
ple of example agents from the system, and illustrate their 
mapping from natural language descriptions through to sim- 
ple Java implementations. 

Let us first illustrate, via a trivial example, how scenarios 
map to CSR Suppose we have the following as part of one 
of the scenarios for the system: 

if the Spacecraft Monitoring Agent receives a 
“fault” advisory from the spacecraft the agent 
sends the fault to the Fault Resolution Agent 
OR 

if the Spacecraft Monitoring Agent receives en- 
gineering data from the spacecraft the agent 
sends the data to the Trending Agent 

That part of the scenario could be mapped to structured 
text as: 

inSMA?fault from Spacecraft 
then outSMAIfault to FIRE 
else 

inengSMA?data from Spacecraft 
then outengSMA!data to TREND 

The laws of concurrency would allow us to derive the 
traces as: 

tSMA D {(), {inSMA, fault), 

(inSMA, fault, outSMA, fault)} [J 
{(), {inengSMA, data), 

(inengSMA, data , outSMA, data) } 
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From the traces, we can infer an equivalent CSP process 
specification as: 

SMA = inSMA? fault — ► {out SM A! fault — > 
SKIP) 

| ( inengSMA?data — ► outengSMAIdata — > 
SKIP ) 

Let us now consider a slightly larger example, the 
LOGOS Pager Agent, and illustrate its implementation in 
Java. The pager agent sends pages to engineers and con- 
trollers when there is a spacecraft anomaly and there is 
no analyst logged on to the system. The pager agent re- 
ceives requests from the user interface agent that no ana- 
lyst is logged on, gets paging information from the database 
agent (which keeps relevant information about each user 
of the system — in this case the analyst’s pager num- 
ber), and, when instructed by the user interface agent that 
the analyst has logged on, stops paging. These scenar- 
ios can be restated in more structured natural language as 
follows: 

if the Pager agent receives a request from the User 


Interface agent, the Pager agent sends a re- 
quest to the database agent for an analyst’s 
pager information and puts the message in a 
list of requests to the database agent 
OR 

if the Pager agent receives a pager number from 
the database agent, then the pager agent re- 
moves the message from the paging queue 
and sends a message to the analyst’s pager and 
adds the analyst to the list of paged people 
OR 

if the Pager agent receives a message from the 
user interface agent to stop paging a particular 
analyst, the pager sends a stop-paging com- 
mand to the analyst’s pager and removes the 
analyst from the paged list 
OR 

if the Pager agent receives another kind of mes- 
sage, reply to the sender that the message was 
not recognized 

The above scenarios would then be translated into CSP. 
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Figure 5. CSP model 
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Figure 7 shows a partial CSP description of the pager agent. 
This specification states that the process PAGER_BUS re- 
ceives a message on its “/in” channel and stores it in a 
variable called “msg”. Depending on the contents of the 
message, one of four different processes is executed. If 
the message has a START_PAGING performative, then the 
GET_USER JNFO process is called with parameters of the 
type of specialist to page (pagee) and the text to send the 
pagee. If the message has a RETURN-DATA performative 
with a pagee ’s pager number, then the database has returned 
a pager number and the BEGIN-PAGING process is exe- 
cuted with a parameter containing the original message id 
(used as a key to the db.waiting set) and the passed pager 
number. The third type of message that the pager agent 
might receive is one with a STOP-PAGING performative. 
This message contains a request to stop paging a particular 
specialist (stored in the pagee parameter). When this mes- 
sage is received, the STOP-PAGING process is executed 
with the parameter of the specialist type. If the pager agent 
receives any other message than the above three messages, 
an error message is returned to the sender of the message 
(which is the first item of the list) stating that the message 
is “UNRECOGNIZED”. After this, the PAGER-BUS pro- 
cess is again executed. 

The R2D2C prototype tool will produce Java code from 
the CSP model as follows: 

class Pager extends Thread { 

Transaction analystmessage; 

Transaction databaserequest; 

Transaction messagenotrecognized; 

Transaction pagernumber; 

Transaction pagerrequest ; 

Transaction stoppaggingmessage; 

boolean running; 

public Pager (Transaction analystmessage. 
Transaction databaserequest. 

Transaction messagenotrecognized. 

Transaction pagernumber, 

Transaction pagerrequest. 

Transaction stoppaggingmessage) { 

this . analystmessage - analystmessage; 
this .databaserequest = databaserequest; 
this . messagenotrecognized = 
messagenotrecognized; 


this .pagernumber = pagernumber; 
this .pagerrequest = pagerrequest; 
this . stoppaggingmessage = 
stoppaggingmessage; } 

public void run () { 

int index = 0; 
running = true; 

while (running) { 
switch (index) { 
case 0: 

while (pagerrequest . committed ( ) == 
false) ; 

Test . out . println ( "pagerrequest" ) ; 

Test . out . flush ( ) ; 

while (databaserequest . committed ( ) == 
false) ; 

Test . out .println ( "databaserequest " ) ; 

Test . out . flush ( ) ; 
break; 
case 1 : 

while (pagernumber . committed ( ) == 
false) ; 

Test . out .println ( "pagernumber " ) ; 

Test . out . flush ( ) ; 

while (analystmessage . committed ( ) == 
false) ; 

Test . out .println ( "analystmessage" ) ; 

Test . out . flush ( ) ; 
break; 
case 2: 

while (stoppaggingmessage . committed ( ) == 
false) ; 

Test .out .println ("stoppaggingmessage" ) ; 
Test . out . flush ( ) ; 
break; 
case 3: 

while (messagenot recognized . committed ( ) == 
false) ; 

Test . out .println ( "messagenotrecognized" ) ; 
Test . out . flush ( ) ; 
break; } 
index++; 
index) } ) 


4.3. Results 

A formal specification of LOGOS in CSP had previously 
been undertaken by hand [17]. This was most insightful, 
highlighting over 80 errors and anomalies in the require- 


ments of a relatively small system (LOGOS is based, essen- 
tially, on ten interacting agents). While many of these were 
minor oversights that would have caused inconveniences, 
others were more significant. 

A great advantage of using an example for which we al- 
ready have a formal specification is that we can compare the 
system derived by our prototype tool with the manually de- 
rived formal specification. 

Our prototype tool was able to uncover all of the er- 
rors and anomalies we found with our manual specification. 
We were surprised when we first ran it to find that it halted 
within seconds, having found yet another error that had been 
introduced into the requirements (due to a typographical er- 
ror) when changes were made following the original manual 
formal specification. The prototype tool can cope with the 
LOGOS requirements, generating a design and a Java im- 
plementation in a matter of minutes, whereas manual speci- 
fication had taken several days and code generation by hand 
took several weeks. 

5. Future Applications 

The prototype tool described in this paper is designed to 
support a NASA patent-pending method for Requirements- 
Based Programming (RBP). The uniqueness of the method 
is not in supporting RBP, but in supporting it with a devel- 
opment process that is mathematically tractable over the en- 
tire development process. This fully formal development of- 
fers levels of assurance and confidence significantly higher 
than traditionally available. 

The method is not limited to producing executable code, 
however [ 1 1 ]. In addition to applying the approach to agent- 
based systems (such as LOGOS) as described in this paper, 
and to Wireless Sensor Networks (WSNs) [12], we are cur- 
rently examining applications of the approach to the verifi- 
cation of expert systems and robotic applications. 

5.1. Expert Systems 

A suitable translator from the C Language Integrated 
Production System (CLIPS) [5], rather than natural lan- 
guage, enables us to use this technology to examine expert 
system rule bases for consistency, etc., with potential appli- 
cation to existing automated ground control center opera- 
tions (e.g., for the POLAR and ACE missions). More sig- 
nificantly, we can generate CLIPS rules from CSP just as 
we would generate code in Java. It is expected that this will 
be a major asset in capturing domain knowledge for expert 
systems, and maintaining correctness throughout the entire 
process of expert system development. 

In addition, it will allow us to reverse engineer, validate, 
and ultimately re-engineer existing rule bases. 


While an expert system might not immediately strike us 
as being an autonomic system, complex expert systems do 
indeed meet all of the necessary criteria. NASA uses expert 
systems, for example, to perform automated ground control 
and monitoring for several classes of spacecraft. Rule bases 
must constantly be updated based on data received from the 
spacecraft, to ensure that the spacecraft is protected from 
unsafe situations, and operating at peak performance. 

5.2. Robotic Operations 

We have begun exploratory work to determine how the 
approach and tool may be used in validating robotic proce- 
dures to be used in the Hubble Robotic Servicing Mission 
(HRSM). 

Robotic devices will be used in the replacement of cam- 
eras, etc. on the Hubble Space Telescope (HST). We expect 
that the tool will prove to be useful in performing what-if 
analysis of ordering of instructions in complex repair pro- 
cesses, in particular where resources (time being one of the 
most precious resources) are limited. 

Additionally, the approach may be useful in actually gen- 
erating instructions for the robotic arm that will be used to 
perform much of the maintenance, in much the same way 
as it currently generates Java code. 

6. Conclusions 

The difficulty of developing many autonomous and auto- 
nomic applications is explained by their inherent complex- 
ity. Often, required autonomous behavior results in emer- 
gent, unexplained behavior that could not, reasonably, have 
been foreseen. The need to exhibit autonomic behavior of- 
ten compounds the situation, giving rise to necessary self- 
managing behavior that could not reasonably be expected to 
be the subject of even the most exhaustive testing plans. 

Only with fully formal underpinnings for the develop- 
ment process can we be assured of correctness [3]. Formal 
development processes will become more and more impor- 
tant in future autonomic computing systems, and the con- 
tinued success of the Autonomic Computing initiative is 
predicated on the ability to develop complex systems that 
both exhibit autonomic self-managing behaviors and oper- 
ate correctly (with respect to their requirements). 

The experience related in this paper leads us to be con- 
fident that such tools will offer greater levels of assurance 
in other domains, and enhance both the quality and perfor- 
mance of future autonomous and autonomic systems. 
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